Add a sparse keyword to reductions along a dimension and reduce column-range views through the sparse kernels - #798

…atrix

Fixes #43. `sum(A; dims)` and the other dimensional reductions of a
`SparseMatrixCSC` returned a dense `Matrix`, which for a hypersparse
matrix costs O(size) time and memory for a result with a handful of
entries. They now return a `SparseMatrixCSC` of the reduced shape that
stores an entry only for the rows or columns that store one themselves,
unless the reduction of a structurally empty slice is nonzero, in which
case the result is fully stored. Results without a `zero`, such as the
tuples of `extrema`, stay dense.

`reducedim_initarray` provides a structurally empty destination when the
initial value is zero and a fully stored one otherwise. A new
`_mapreducedim!` for a sparse destination reduces a fully stored one as
the dense array its values form, fills an empty one without touching the
slices that store nothing, and sends anything in between through the
element-wise kernel. Row reductions build the `1 x n` result column by
column. Column reductions use the result's value vector as a dense
workspace compressed in place when there are enough stored entries, and
otherwise sort the stored entries by row so that only rows storing
something are visited.

Measured on nightly against main, min of 9: `sum(A; dims=2)` for a
10^7 x 150 matrix with 151 entries goes from 6.5 ms and 156 MiB to
2.3 µs and 16 KiB; for 10^4 x 10^4 at 1e-3 and 1e-2 density the
reductions are within noise, with the result's extra index vectors as
the only added allocation.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V6EdE4F3CCGE3vxr8gQYKf

Fixes #377.

`sum(view(A, :, j:k); dims)` and the other reductions of a column-range
view went through Base's element-wise fallback, indexing the parent once
per element. The reduction kernels only need the column pointers, row
indices and values, which a `SparseMatrixCSCView` already exposes off
the parent's storage, so they now accept `SparseMatrixCSCUnion`. The two
fully-stored fast paths index through the column pointers rather than
assuming the values start at one, and the hypersparse column reduction
sorts the view's stored range. `nnz` of such a view is now O(1).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DzbyurS9gH2pdqWJrWaPxD

Reductions along a dimension of a sparse matrix return a dense `Matrix` again, as
before this PR and as for dense input: the result has one dimension fewer and is
usually dense, and downstream code expects it dense. The sparse result is now
opt-in by reducing into a sparse destination, `sum!(spzeros(size(A, 1), 1), A)` or
`Base.mapreducedim!` and the other in-place reductions, which keeps the hypersparse
kernels and their cost proportional to the stored entries plus the length of the
result. A destination that stores only zeros, as a reused `sum!` destination does
after its `fill!`, folds like an empty one so that reuse stays on the fast path.
Column-range views keep reducing off the parent's storage and now return the same
dense result as their copy, where Base's `similar` gave them a sparse one.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DGaTC2P39YrE2aAU5es55x

…e destination

`sum(A; dims = 2, sparse = true)` and the other reductions along a dimension
now return a `SparseMatrixCSC`; reducing into a sparse destination is no
longer special-cased. Base forwards unknown keywords from `sum`, `prod`,
`maximum`, `minimum` and `extrema` to `mapreduce`, so one `mapreduce` method
on the sparse types carries the keyword; `any`, `all` and `count` do not
forward it and get their own methods.

Without a destination the kernels can no longer rely on `sum!` and friends
having initialized it, so each slice is now seeded the way Base seeds the
dense result: with `init` when given, otherwise with `mapreduce_first` of its
first stored entry, and the unstored entries folded in afterwards. The
element type and the value of a slice with nothing to reduce come from Base's
`reducedim_init` on a stand-in, so they match the dense result exactly,
including the widening of small integers and the error for `maximum` over an
empty axis.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgWK99c6dYwt3gxH44MxCs

…trim the tests

`extrema(A; dims, sparse = true)` failed with a MethodError on `zero(Tuple)`;
it now throws an ArgumentError. `any` and `all` with `sparse = true` accept
callables that are not `Function`s. The reduction grid in the tests drops
three pairs that exercise no new path, and gains complex, callable and
`extrema` cases.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>